REMARKS 



1. Present Status of Patent Application 

This is a full and timely response to the outstanding final Office Action of 
February 24, 2009. Claims 1, 10, 16, 19, 24-25, 27, and 29-32 have been amended, 
claims 4, 15, and 28 have been canceled without prejudice, waiver, or disclaimer, and 
claims 1, 3, 5-11, 13-14, 16-19, 21-25, 27, and 29-32 remain pending in the present 
application. Reconsideration and allowance of the application and presently pending 
claims are respectfully requested. 

2. Response to Rejections of Claims under 35 U.S.C. §1 01 

Claims 1,3-9, 19, and 21-23 have been rejected under 35 U.S.C. §101 as allegedly 
being directed to non-statutory subject matter. The Office Action contends that the 
claimed subject matter is directed towards a file handling system which is "nothing more 
than software components." 

In response, independent claims 1 and 19 have been amended to recite a 
processor-a hardware component-in order to address the Examiner's concerns. For at 
least these reasons, the rejection of claims 1 , 3-9, 19, and 21-23 should be withdrawn. 

In addition, claims 24-25 and 27-32 have been rejected under 35 U.S.C. §101 as 
allegedly being directed to non-statutory subject matter. The Office Action contends that 
the claimed subject matter pertains to a computer-readable storage medium which is 
defined to be a paper storage medium. Claims 24-25 and 27-32 have been amended to 
recite a computer diskette which is statutory subject matter and is disclosed in Applicant's 
specification. As a result, the rejection of claims 24-25 and 27-32 should be withdrawn. 



3. 



Response to Rejections of Claims under 35 U.S.C. 5103 



Claims 1, 3-11, 13-19, 21-22, 24-25, and 27-32 have been rejected under 35 
U.S.C. §1 03(a) as allegedly being unpatentable over Persels (U.S. Patent No. 
7,065,547) in view of Hashem (U.S. Patent No. 7,155,578). 



a. Claim 1 

As provided in independent claim 1 , Applicant claims: 
A file handling system, comprising: 

a terminating file transfer server operable to receive a file transfer 
message from an originating file transfer server along with at least one file, 
the file transfer message including details about the transfer of said at 
least one file including a local user and at least one filename for said at 
least one file, the terminating file transfer server in response to 
receiving the file transfer message, executing an agent; 

the agent operable to read the file transfer message received 
from the originating file transfer server, and direct the transfer of 
said at least one filename and said at least one file associated with 
said at least one filename to a home directory associated with the 
local user in accordance with instructions from a configuration file 
residing in the home directory; and 

the configuration file residing in the home directory, and 
operable to instruct the agent to, after saving the at least one file to 
the home directory, transfer said at least one file from the home 
directory to a remote host specified in the configuration file, wherein 
the configuration file comprises a host name and a port name of the 
remote host thereby allowing transfer of said at least one file to the 
remote host without necessitating the remote host being logged on 
the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 1 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"the terminating file transfer server in response to receiving the file transfer message, 
executing an agent; the agent operable to read the file transfer message received from 
the originating file transfer server, and direct the transfer of said at least one filename 
and said at least one file associated with said at least one filename to a home directory 
associated with the local user in accordance with instructions from a configuration file 
residing in the home directory; and the configuration file residing in the home directory, 
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and operable to instruct the agent to, after saving the at least one file to the home 
directory, transfer said at least one file from the home directory to a remote host 
specified in the configuration file, wherein the configuration file comprises a host name 
and a port name of the remote host thereby allowing transfer of said at least one file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "the terminating file transfer server in response to receiving the 
file transfer message, executing an agent; the agent operable to read the file transfer 
message received from the originating file transfer server, and direct the transfer of said 
at least one filename and said at least one file associated with said at least one 
filename to a home directory associated with the local user in accordance with 
instructions from a configuration file residing in the home directory; and the 
configuration file residing in the home directory, and operable to instruct the agent to, 
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after saving the at least one file to the home directory, transfer said at least one file from 
the home directory to a remote host specified in the configuration file, wherein the 
configuration file comprises a host name and a port name of the remote host thereby 
allowing transfer of said at least one file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server," as recited in claim 1 . 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 1. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrievinq-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10 . That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66 ." Cols. 8-9, lines 47-2 (Emphasis added and 
indentation removed). Therefore, an internal inbasket appears to more akin to a home 
directory, using the language of claim 1, than to a remote host. It is noted that claim 1 
requires a file to be received at a terminating file transfer server, transferred and stored 
in a home directory by an agent, and then transferred from the home directory to a 
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remote host as specified in a configuration file residing in the home directory. Hashem 
does not satisfy these requirements and does not remedy the deficiencies of Persels. 

As such, Persels in view of Hashem fails to teach or suggest at least "the 
terminating file transfer server in response to receiving the file transfer message, 
executing an agent; the agent operable to read the file transfer message received from 
the originating file transfer server, and direct the transfer of said at least one filename 
and said at least one file associated with said at least one filename to a home directory 
associated with the local user in accordance with instructions from a configuration file 
residing in the home directory; and the configuration file residing in the home directory, 
and operable to instruct the agent to, after saving the at least one file to the home 
directory, transfer said at least one file from the home directory to a remote host 
specified in the configuration file, wherein the configuration file comprises a host name 
and a port name of the remote host thereby allowing transfer of said at least one file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as recited in claim 1 . 

Accordingly, claim 1 is patentable over Persels in view of Hashem, and the 
rejection of claim 1 should be withdrawn. 

b. Claims 3-9 

For at least the reasons given above, claim 1 is allowable over the cited art of 
record. Since claims 3 and 5-9 depend from and include the features of claim 1 and recite 
additional features, claims 3 and 5-9 are allowable as a matter of law over the cited art of 
record. 

Claim 4 is canceled without prejudice, waiver, or disclaimer, and therefore, the 
rejection to the claim is rendered moot. Applicant takes this action merely to reduce the 
number of disputed issues and to facilitate early allowance and issuance of other claims in 
the present application. Applicant reserves the right to pursue the subject matter of the 
canceled claim in a continuing application, if Applicant so chooses, and does not intend to 
dedicate any of the canceled subject matter to the public. 
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c. Claim 10 



As provided in independent claim 10, Applicant claims: 

A method of handling files on a ConnectDirect server, comprising: 
receiving a file transfer message from an originating file transfer 

server at a terminating file transfer server; 

in response to receiving the file transfer message, executing 

an agent; 

determining, by the agent, a home directory from a local user 
associated with the file transfer message; 

storing at least one file associated with the file transfer 
message in the home directory; 

retrieving, by the agent, a configuration file from the home 
directory, wherein the configuration file comprises a host name and 
a port name of a remote host; and 

transmitting, via the agent, said at least one file responsive to 
the configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 10 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"in response to receiving the file transfer message, executing an agent; determining, by 
the agent, a home directory from a local user associated with the file transfer message; 
storing at least one file associated with the file transfer message in the home directory; 
retrieving, by the agent, a configuration file from the home directory, wherein the 
configuration file comprises a host name and a port name of a remote host; and 
transmitting, via the agent, said at least one file responsive to the configuration file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
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24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "in response to receiving the file transfer message, executing 
an agent; determining, by the agent, a home directory from a local user associated with 
the file transfer message; storing at least one file associated with the file transfer 
message in the home directory; retrieving, by the agent, a configuration file from the 
home directory, wherein the configuration file comprises a host name and a port name 
of a remote host; and transmitting, via the agent, said at least one file responsive to the 
configuration file to the remote host without necessitating the remote host being logged 
on the terminating file transfer server," as recited in claim 10. 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 10. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
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In a similar manner when downloading or retrieving-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to more akin to a home directory, using the 
language of claim 10, than to a remote host. It is noted that claim 10 requires a file to 
be received at a terminating file transfer server, transferred and stored in a home 
directory by an agent, and then transferred from the home directory to a remote host as 
specified in a configuration file residing in the home directory. Hashem does not satisfy 
these requirements and does not remedy the deficiencies of Persels. 

As such, Persels in view of Hashem fails to teach or suggest at least "in 
response to receiving the file transfer message, executing an agent; determining, by the 
agent, a home directory from a local user associated with the file transfer message; 
storing at least one file associated with the file transfer message in the home directory; 
retrieving, by the agent, a configuration file from the home directory, wherein the 
configuration file comprises a host name and a port name of a remote host; and 
transmitting, via the agent, said at least one file responsive to the configuration file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as recited in claim 10. 

Accordingly, claim 10 is patentable over Persels in view of Hashem, and the 
rejection of claim 10 should be withdrawn. 

d. Claims 11 and 13-18 

For at least the reasons given above, claim 10 is allowable over the cited art of 
record. Since claims 11, 13-14, and 16-18 depend from and include the features of claim 
10 and recite additional features, claims 11, 13-14, and 16-18 are allowable as a matter of 
law over the cited art of record. 
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Claim 15 is canceled without prejudice, waiver, or disclaimer, and therefore, the 
rejection to the claim is rendered moot. Applicant takes this action merely to reduce the 
number of disputed issues and to facilitate early allowance and issuance of other claims in 
the present application. Applicant reserves the right to pursue the subject matter of the 
canceled claim in a continuing application, if Applicant so chooses, and does not intend to 
dedicate any of the canceled subject matter to the public. 



e. Claim 19 

As provided in independent claim 19, Applicant claims: 

A ConnectDirect file handling system, comprising: 

a terminating file transfer server; 

an agent; and 

a configuration file; 

the terminating file transfer server being operable to launch 
the agent upon receipt of a file transfer message, the file transfer 
message comprising a local username and at least one filename, and 
the agent being operable to direct the transfer of and storage of at 
least one file associated with the filename to a home directory 
associated with the username, the agent being further operable to 
read the configuration file, and transfer said at least one file from the 
home directory to a remote host specified by the configuration file 
without necessitating the remote host being logged on the 
terminating file server, wherein the configuration file is operable to 
store a host name and a port number associated with the remote 
host. 

(Emphasis added). 

Applicant respectfully submits that independent claim 19 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"the terminating file transfer server being operable to launch the agent upon receipt of a 
file transfer message, the file transfer message comprising a local username and at 
least one filename, and the agent being operable to direct the transfer of and storage of 
at least one file associated with the filename to a home directory associated with the 
username, the agent being further operable to read the configuration file, and transfer 
said at least one file from the home directory to a remote host specified by the 
configuration file without necessitating the remote host being logged on the terminating 
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file server, wherein the configuration file is operable to store a host name and a port 
number associated with the remote host," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "the terminating file transfer server being operable to launch 
the agent upon receipt of a file transfer message, the file transfer message comprising a 
local username and at least one filename, and the agent being operable to direct the 
transfer of and storage of at least one file associated with the filename to a home 
directory associated with the username, the agent being further operable to read the 
configuration file, and transfer said at least one file from the home directory to a remote 
host specified by the configuration file without necessitating the remote host being 
logged on the terminating file server, wherein the configuration file is operable to store a 
host name and a port number associated with the remote host," as recited in claim 19. 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 19. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
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an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrieving-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to more akin to a home directory, using the 
language of claim 19, than to a remote host. It is noted that claim 19 requires a file to 
be received at a terminating file server, transferred and stored in a home directory by an 
agent, and then transferred from the home directory to a remote host as specified in a 
configuration file residing in the home directory. Hashem does not satisfy these 
requirements and does not remedy the deficiencies of Persels. 

As such, Persels in view of Hashem fails to teach or suggest at least "the 
terminating file transfer server being operable to launch the agent upon receipt of a file 
transfer message, the file transfer message comprising a local username and at least 
one filename, and the agent being operable to direct the transfer of and storage of at 
least one file associated with the filename to a home directory associated with the 
username, the agent being further operable to read the configuration file, and transfer 
said at least one file from the home directory to a remote host specified by the 
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configuration file without necessitating the remote host being logged on the terminating 
file server, wherein the configuration file is operable to store a host name and a port 
number associated with the remote host," as recited in claim 19. 

Accordingly, claim 19 is patentable over Persels in view of Hashem, and the 
rejection of claim 19 should be withdrawn. 

f. Claims 21 -23 

For at least the reasons given above, claim 19 is allowable over the cited art of 
record. Since claims 21-23 depend from and include the features of claim 19 and recite 
additional features, claims 21-23 are allowable as a matter of law over the cited art of 
record. 

Further, with regard to claim 23, the Office Action states "it would have been well- 
known in the networking art to include a rename function into the system and method by 
Persels-Hashem. The motivation for said combination would have been to enable a 
user to indicate a preferred (e.g. more easily remembered) file name." Page 15. 
Applicant respectfully traverses the finding for at least the reason that the Office Action 
describes its rename function as being equivalent to a user manually selecting a file 
name. Page 15. However, this manual operation is not equivalent to "the file processor 
being operable to receive files via the port monitor, and assign said at least one 
filename to said at least one file received, respectively," as recited in claim 23. 
Therefore, Applicant respectfully submits that it has not been established that a "the file 
processor being operable to receive files via the port monitor, and assign said at least 
one filename to said at least one file received, respectively," as described in claim 23, is 
capable of instant and unquestionable demonstration as being well-known. 
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g. Claim 24 



As provided in independent claim 24, Applicant claims: 

A computer diskette having a program for handling files on a 
ConnectDirect server, wherein the computer diskette is a physical 
structure executed by a computer and the program is operable to perform: 

receiving a file transfer message from an originating file transfer 
server at a terminating file transfer server; 

in response to receiving the file transfer message, executing 
an agent; 

determining, by the agent, a home directory from a local user 
associated with the file transfer message; 

storing at least one file associated with the file transfer 
message in the home directory; 

retrieving, by the agent, a configuration file from the home 
directory, wherein the configuration file comprises a host name and 
a port name of a remote host; and 

transmitting, via the agent, said at least one file responsive to 
the configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 24 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"in response to receiving the file transfer message, executing an agent; determining, by 
the agent, a home directory from a local user associated with the file transfer message; 
storing at least one file associated with the file transfer message in the home directory; 
retrieving, by the agent, a configuration file from the home directory, wherein the 
configuration file comprises a host name and a port name of a remote host; and 
transmitting, via the agent, said at least one file responsive to the configuration file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
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message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "in response to receiving the file transfer message, executing 
an agent; determining, by the agent, a home directory from a local user associated with 
the file transfer message; storing at least one file associated with the file transfer 
message in the home directory; retrieving, by the agent, a configuration file from the 
home directory, wherein the configuration file comprises a host name and a port name 
of a remote host; and transmitting, via the agent, said at least one file responsive to the 
configuration file to the remote host without necessitating the remote host being logged 
on the terminating file transfer server," as recited in claim 24. 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 24. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
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information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrieving-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to more akin to a home directory, using the 
language of claim 24, than to a remote host. It is noted that claim 24 requires a file to 
be received at a terminating file transfer server, transferred and stored in a home 
directory by an agent, and then transferred from the home directory to a remote host as 
specified in a configuration file residing in the home directory. Hashem does not satisfy 
these requirements and does not remedy the deficiencies of Persels. 

As such, Persels in view of Hashem fails to teach or suggest at least "in 
response to receiving the file transfer message, executing an agent; determining, by the 
agent, a home directory from a local user associated with the file transfer message; 
storing at least one file associated with the file transfer message in the home directory; 
retrieving, by the agent, a configuration file from the home directory, wherein the 
configuration file comprises a host name and a port name of a remote host; and 
transmitting, via the agent, said at least one file responsive to the configuration file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as recited in claim 24. 

Accordingly, claim 24 is patentable over Persels in view of Hashem, and the 
rejection of claim 24 should be withdrawn. 
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h. Claims 26-32 

For at least the reasons given above, claim 24 is allowable over the cited art of 
record. Since claims 25, 27, and 29-32 depend from and include the features of claim 24 
and recite additional features, claims 25, 27, and 29-32 are allowable as a matter of law 
over the cited art of record. 

Claim 28 is canceled without prejudice, waiver, or disclaimer, and therefore, the 
rejection to the claim is rendered moot. Applicant takes this action merely to reduce the 
number of disputed issues and to facilitate early allowance and issuance of other claims in 
the present application. Applicant reserves the right to pursue the subject matter of the 
canceled claim in a continuing application, if Applicant so chooses, and does not intend to 
dedicate any of the canceled subject matter to the public. 
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CONCLUSION 

Any other statements in the Office Action that are not explicitly addressed herein 
are not intended to be admitted. In addition, any and all findings of inherency are 
traversed as not having been shown to be necessarily present. Furthermore, any and all 
findings of well-known art and official notice, or statements interpreted similarly, should 
not be considered well known for at least the specific and particular reason that the 
Office Action does not include specific factual findings predicated on sound technical 
and scientific reasoning to support such conclusions. 

For at least the reasons set forth above, Applicant respectfully submits that all 
objections and/or rejections have been traversed, rendered moot, and/or 
accommodated, and that the pending claims are in condition for allowance. Favorable 
reconsideration and allowance of the present application and all pending claims are 
hereby courteously requested. In addition, Applicant reserves the right to address any 
comments made in the Office Action that were not specifically addressed herein. Thus, 
such comments should not be deemed admitted by the Applicant. If, in the opinion of 
the Examiner, a telephonic conference would expedite the examination of this matter, the 
Examiner is invited to call the undersigned agent at (770) 933-9500. 

Respectfully submitted, 

/Charles W. Griqqers/ 

Charles W. Griggers, Reg. No. 47,283 

AT&T Legal Department - TKHR 

Attn: Patent Docketing 
One AT&T Way 
Room 2A-207 
Bedminster, NJ 07921 
Customer No.: 38823 
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